В руководство добавили различные рекомендации и новые максимальные значения инфраструктуры, касающиеся именно vSphere 8 Update 2 и vSAN 8 Update 2.
Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere (страница 11)
ESXi and Virtual Machines (страница 25)
Guest Operating Systems (страница 55)
Virtual Infrastructure Management (страница 67)
Предполагается, что читатель уже в достаточной степени осведомлен о методах управления виртуальной инфраструктурой и ее основных компонентах.
Скачать Performance Best Practices for VMware vSphere 8.0 Update 2 можно по этой ссылке.
Еще в 2015 году мы писали о том, что проект VMware Sample Exchange вышел в бета-версии. Это портал, предназначенный для разработчиков средств автоматизации виртуальной инфраструктуры, где они могут скачивать примеры кода на разных языках и для разных платформ под множество компонентов виртуальной среды.
За прошедшие 8 лет этот проект накопил огромное количество различных сценариев и примеров кода как от сотрудников VMware, так и от сообщества разработчиков, которые постоянно добавляют туда новые сэмплы (вы тоже можете это делать).
Если при первоначальном запуске портала там было всего 250 сэмплов, то теперь их стало более двух тысяч, как видно на скиншоте ниже:
Посмотрите, какое огромное количество языков и платформ представлено на портале, одних только дэшбордов для решения vRealize (Aria) Operations - 300 штук!
Примерно столько же представлено и сценариев для автоматизации инфраструктуры средствами PowerShell/PowerCLI, а вот это уже - большая находка.
Microsoft SQL Server долгое время считается золотым стандартом для критически важных рабочих нагрузок баз данных среднего класса. Однако полноценное использование возможностей SQL Server требует соответствующей инфраструктуры.
Партнерство между Lenovo для линейки ThinkAgile VX Series и VMware в рамках технологии vSAN Express Storage Architecture (ESA) позволяет создать передовую гиперконвергентную инфраструктуру (HCI), работающую на новейших аппаратных платформах. Это решение разработано для удовлетворения сложных потребностей современных организаций, ориентированных на данные.
В VMware vSAN 8 и vSAN ESA произошли значительные изменения, которые включают в себя использование высокопроизводительных NVMe-дисков и новый, быстрый и эффективный путь передачи данных. vSAN ESA обеспечивает эффективность RAID 5/6 с производительностью RAID 1.
Тестирование показало, что 8-узловой кластер vSAN ESA на Lenovo Agile VX Series может обеспечить 720 000 агрегированных IOPS по мере увеличения количества виртуальных машин SQL Server с одной до восьми. Результаты подтверждают последовательную масштабируемость и надежную производительность для рабочих нагрузок.
В документе приведены обширные рекомендации по проектированию и сайзингу, отчеты о проверке решений и лучшие практики для администраторов и владельцев систем на основе Microsoft SQL Server.
Таги: VMware, vSAN, ESA, Storage, Microsoft, SQL, Performance
На конференции VMworld 2020 Online ковидного года компания VMware представила одну из самых интересных своих инициатив по сотрудничеству с вендорами оборудования - Project Monterey. Тогда была представлена технология SmartNIC/DPU, которая позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.
SmartNIC - это специальный сетевой адаптер (NIC) c модулем CPU на борту, который берет на себя offload основных функций управляющих сервисов (а именно, работу с хранилищами и сетями, а также управление самим хостом).
В данном решении есть три основных момента:
Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличивает пропускную способность и уменьшает задержки (latency).
Унифицированные операции для всех приложений, включая bare-metal операционные системы.
Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности. Ведь если основной ESXi для исполнения рабочих нагрузок будет скомпрометирован, то управляющий DPU сможет обнаружить ее и устранить уязвимость.
В статье об аппаратных нововведениях платформы VMware vSphere 8 Update 2, представленных на конференции Explore 2023, мы писали о том, что VMware еще в vSphere 8 представила поддержку DPU, позволяя клиентам переносить инфраструктурные рабочие нагрузки с CPU на специализированный модуль DPU, тем самым повышая производительность бизнес-нагрузок. Ну а в vSphere 8 U2 клиенты, использующие серверы Lenovo или Fujitsu, теперь смогут использовать новые функции интеграции vSphere DPU и его преимущества в производительности.
Теперь в платформах vSphere 8 и NSX есть полноценная поддержка устройств SmartNIC или так называемых устройств обработки данных (DPU). Реализация DPU в vSphere называется vSphere Distributed Service Engine.
DPU (SmartNIC) — это сетевые карты с встроенным интеллектом, которые могут выполнять различные сетевые функции непосредственно на адаптере через свои собственные программируемые процессоры. В дополнение к сетевым ускорителям, такие DPU, как NVIDIA BlueField, также имеют ядра общего назначения на базе процессора Arm, которые могут запускать полноценную систему ESXi (вот для чего и пригодился гипервизор VMware ESXi Arm Edition).
С технологией DPU, службы NSX, такие как маршрутизация, коммутация, брандмауэр и мониторинг, снимаются с хост-гипервизора и переносятся на DPU. С помощью этих возможностей возможно улучшить производительность, освободить ресурсы на хосте и изолировать рабочую нагрузку и инфраструктурные домены.
Ну и несколько картинок по результатам тестирования хостов ESXi с модулями SmartNIC/DPU на борту, которые показывают, какой прирост производительности дает новая технология:
Недавно опубликованный компанией VMware технический документ "Troubleshooting TCP Unidirectional Data Transfer Throughput" описывает, как устранить проблемы с пропускной способностью однонаправленной (Unidirectional) передачи данных по протоколу TCP. Решение этих проблем, возникающих на хосте vSphere/ESXi, может привести к улучшению производительности. Документ предназначен для разработчиков, опытных администраторов и специалистов технической поддержки.
Передача данных по протоколу TCP очень распространена в средах vSphere. Примеры включают в себя трафик хранения между хостом VMware ESXi и хранилищем данных NFS или iSCSI, а также различные формы трафика vMotion между хранилищами данных vSphere.
В компании VMware обратили внимание на то, что даже крайне редкие проблемы с TCP могут оказывать несоразмерно большое влияние на общую пропускную способность передачи данных. Например, в некоторых экспериментах с чтением NFS из хранилища данных NFS на ESXi, кажущаяся незначительной потеря пакетов (packet loss) в 0,02% привела к неожиданному снижению пропускной способности чтения NFS на 35%.
В документе описывается методология для выявления общих проблем с TCP, которые часто являются причиной низкой пропускной способности передачи данных. Для этого производится захват сетевого трафика передачи данных в файл трассировки пакетов для офлайн-анализа. Эта трассировка пакетов анализируется на предмет сигнатур общих проблем с TCP, которые могут оказать значительное влияние на пропускную способность передачи данных.
Рассматриваемые проблемы с TCP включают в себя потерю пакетов и их переотправку (retransmission), длительные паузы из-за таймеров TCP, а также проблемы с Bandwidth Delay Product (BDP). Для проведения анализа используется решение Wireshark и описывается профиль для упрощения рабочего процесса анализа. VMware описывает системный подход к выявлению общих проблем с протоколом TCP, оказывающих значительное влияние на пропускную способность канала передачи данных - поэтому инженерам, занимающимся устранением проблем с производительностью сети, рекомендуется включить эту методологию в стандартную часть своих рутинных проверок.
В документе рассмотрены рабочие процессы для устранения проблем, справочные таблицы и шаги, которые помогут вам в этом нелегком деле. Также в документе есть пример создания профиля Wireshark с предустановленными фильтрами отображения и графиками ввода-вывода, чтобы упростить администраторам процедуру анализа.
Скачать whitepaper "Troubleshooting TCP Unidirectional Data Transfer Throughput" можно по этой ссылке.
На сайте проекта VMware Labs вышло небольшое обновление утилиты Power Actions версии 1.0.3. Напомним, что о прошлой версии мы писали вот тут. Это средство представляет собой плагин для клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI пользователями, не имеющими опыта работы с PowerShell. Утилита также реализует библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации.
Давайте посмотрим, что нового в VMware Power Actions 1.0.3:
В апреле этого года мы писали о первой версии самостоятельного (ранее это были функции HTML5 клиента) решения VMware Power Actions 1.0. Этот продукт представляет собой плагин для клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI пользователями, не имеющими опыта работы с PowerShell. Средство также реализует библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации.
Пользователи могут легко выполнить эти скрипты, используя удобный интерфейс для указания параметров скрипта.
Это обеспечивает мощный механизм расширения клиента vSphere с помощью настраиваемых сценариев PowerCLI. Все скрипты выполняются с использованием прав пользователя, который вошел в клиент vSphere. Таким образом, если у пользователя нет разрешения на выполнение определенных операций, он не сможет выполнить эти операции с помощью Power Actions.
Вот как это работает:
На днях на сайте проекта VMware Labs стала доступна обновленная версия Power Actions 1.0.2. Давайте посмотрим, что там нового:
Исправление для бага 1491 (установка не выполняется, когда отсутствует интернет-соединение)
Добавлены настройки прокси-сервера, позволяющие развертывание в средах с проксированием (баг 1495)
Настройка Thumbprint сервера vCenter заменена на настройку Disable vCenter Server Certificate Verification (отключение проверки сертификатов)
Установка изменена так, чтобы она не завершалась неудачей, если пароль виртуального модуля (Virtual Appliance) не был успешно установлен.
Загрузить виртуальный модуль VMware Power Actions 1.0.2 можно по этой ссылке. Кстати, небольшое количество исправлений за столь долгое время говорит о том, что в целом-то инструмент работает хорошо.
Как и всегда, документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere
ESXi and Virtual Machines
Guest Operating Systems
Virtual Infrastructure Management
Все рекомендации, который были даны для vSphere 8, по-прежнему, в силе, мы не нашли новых моментов, касающихся именно Update 1. Но некоторые косметические и уточняющие правки в документе все-таки есть.
Администраторам настоятельно рекомендуется заглядывать в это руководство, хоть оно и состоит из ста страниц. Там просто огромное количество полезной информации, которую можно использовать ежедневно для поддержания высокого уровня производительности виртуальной среды.
Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.
Архитектура Express Storage Architecture (ESA) в vSAN 8 реализует новый способ обработки и хранения данных. Она предоставляет пользователям совершенно новые возможности, обеспечивает лучшую производительность и улучшает эффективность использования дискового пространства, при этом потребляя меньше ресурсов процессора.
В vSAN 8 U1 было представлено два новых, очень полезных улучшения для повышения производительности и эффективности обработки хранимых данных. Давайте рассмотрим это более подробно, чтобы понять, что это за улучшения, и при каких условиях они будут полезны.
1. Алгоритм VMware vSAN ESA Adaptive Write Path
Новый адаптивный путь записи в vSAN 8 U1 предоставляет ESA один из двух методов записи данных. Стандартный путь записи обрабатывает операции ввода-вывода (I/O) разных размеров, в то время как новый альтернативный путь записи оптимизирован для обработки больших I/O от гостевых ВМ. Зачем здесь два способа записи данных? Немного контекста поможет объяснить, почему это так важно.
Современные флэш-устройства предпочитают обрабатывать запись некоторого минимального объема данных. Это помогает уменьшить износ и активности по сбору мусора на устройствах. vSAN ESA была специально разработана для записи блоков данных, оптимально подходящих для этих устройств. Однако ESA также записывает данные эффективным образом с использованием минимального количества усилий. Для достижения этого используется кодирование RAID-5/6, где данные записываются в полные полосы (full stripe writes). Такие записи избегают шагов чтение-модификация-запись, часто связанных с записью данных с использованием erasure codes.
К сожалению, ВМ не всегда записывают данные большими блоками. Часто они обновляют только небольшие объемы данных. Учитывая это, ESA использует журналируемую (log-structured) файловую систему для объединения входящих операций ввода-вывода и сохранения данных и метаданных в журнал, чтобы можно было отправить подтверждение записи как можно быстрее. Это обеспечивает низкую и стабильную задержку для ВМ. Ну а данные из журнала записываются полной полосой (full stripe) позже. Это представляет собой стандартный путь записи (default write path), который был реализован в ESA на платформе vSAN 8.
Однако ВМ часто могут выполнять и крупные записи. Именно адаптивный путь записи в vSAN 8 U1 помогает записывать данные в таких условиях оптимальным образом. Когда vSAN определяет ситуацию, когда идут записи с использованием больших размеров I/O или большого количества ожидающих I/O, он будет использовать новый путь записи для больших I/O.
ESA в vSAN 8 U1 фиксирует эти I/O из буфера в памяти как полную полосу записи (full stripe) и записывает только метаданные в журналируемую файловую систему. Подтверждение записи будет отправлено ВМ, когда данные будут записаны напрямую в полную полосу записи на диск, а метаданные - в устойчивый журнал (durable log). Несмотря на то что основные данные обходят durable log, очень небольшое количество метаданных все же записывается для избыточности на двойное или тройное зеркало (в зависимости от назначенной политики хранения), чтобы гарантировать надежное хранение блоков.
Этот процесс принятия решений vSAN происходит в реальном времени для каждого объекта. В нем предусмотрены механизмы, помогающие определить, соответствуют ли последующие I/O критериям этого пути записи для больших I/O (это происходит в течение нескольких микросекунд) и вернуться к стандартному пути записи, если это не так.
Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).
2. Оптимизированный процессинг операций ввода-вывода для отдельных объектов VMDK
vSAN ESA улучшает путь данных в стеке обработки таким образом, что позволяет ВМ обрабатывать операции ввода-вывода на новых уровнях. Это не только позволяет быстрее записывать и читать данные, но также помогает инженерным командам VMware выявить новые области в стеке для оптимизации, чтобы еще больше увеличить производительность. Процессы внутри программного обеспечения часто написаны с учетом определенных пределов оборудования и других процессов в стеке. С появлением новых аппаратных технологических решений эти процессы должны быть написаны так, чтобы использовать этот новый потенциал производительности.
vSAN 8 U1 вводит дополнительные вспомогательные потоки в распределенном менеджере объектов - слое стека vSAN, который отвечает за координацию и обработку операции ввода-вывода к объекту. Эти вспомогательные потоки помогают распределять усилия между большим количеством ядер процессора и помогают уменьшить истощение ресурсов процессора, если отдельный процесс перегружен.
Это увеличение параллелизма будет наиболее заметным на ресурсоемких ВМ, обрабатывающих большое количество I/O на VMDK, которые ранее были ограничены стеком каким-либо образом. Будь то критически важные приложения или системы с интенсивной транзакционной активностью, пользователи смогут увидеть улучшение производительности IOPS и пропускной способности до 25%.
Внутренние тесты VMware показали, что это улучшение позитивно скажется на различных типах рабочих нагрузок, включая ВМ, осуществляющие большие последовательные записи, а также мелкие случайные чтения. Даже когда рабочие нагрузки не получают прямой выгоды от этой функции, может быть второй порядок выгоды, где сокращение конкурирующих процессов и ресурсов позволит другим несвязанным действиям, использующим те же общие ресурсы, завершить свои процессы быстрее.
В начале этого года компания VMware выпустила значимое обновление решения vSAN 8 Update 1, где было заявлено достаточно много улучшений в сфере производительности, особенно для архитектуры vSAN ESA (например, Adaptive Write Path).
Сегодня мы посмотрим на то, как эти улучшения в действительности влияют на разные типы приложений в рамках архитектуры кластеров Express Storage Architecture.
1. Приложения для видеонаблюдения
Эти типы решений часто генерируют большие объемы последовательных записей, которые для системы хранения могут быть одним из наиболее требовательных типов профилей рабочей нагрузки, потому что записывается большое количество данных с использованием больших размеров операций ввода-вывода (I/O). При сравнении производительности с OSA (Original Storage Architecture) в VMware обнаружили, что ESA предоставляет улучшение производительности до 240%. То есть вы можете увеличить обмен I/O более чем в три раза, используя то же самое оборудование! Это улучшение демонстрирует возможности нового алгоритма Adaptive Write Path, добавленного в vSAN 8 U1, который может определить, когда происходят такие операции записи, и использовать наиболее оптимальный путь записи для этих условий.
2. Сервисы Apache Kafka
Характеристики потока ввода-вывода Apache Kafka имеют некоторые сходства с приложениями для видеотрансляции, где они могут предъявлять высокие требования к системе хранения. Распределенные решения для потоковой передачи событий, такие как Kafka, были разработаны для удобного масштабирования, и в зависимости от конфигурации, могут генерировать очень большие объемы данных для непрерывной записи. При проведении сравнительных тестов в VMware обнаружили, что ESA обеспечивает улучшение производительности до 80% при работе с Kafka. И это также демонстрирует, насколько хорошо ESA справляется с рабочими нагрузками, генерирующими плотный поток записи.
3. Приложения в сфере здравоохранения
Продукты, использующие реляционные базы данных, являются основой многих приложений в широком спектре отраслей. Отрасль здравоохранения в большой степени зависит от решений Electronic Health Records (EHR), чтобы обеспечивать наилучший уход за пациентами, что является ярким примером "критически важных" приложений. vSAN всегда была идеальной платформой для среды здравоохранения, и с появлением ESA она стала еще лучше. Тесты VMware показали, что эти зависящие от баз данных медицинские приложения предлагают до 50% лучшую производительность при работе на платформе ESA. Это впечатляющий уровень улучшений, учитывая высокую транзакционную природу этих приложений.
4. NoSQL приложения
Некоторые решения используют нереляционную базу данных NoSQL для хранения данных своих приложений. NoSQL может просто масштабироваться и часто используется в ряде открытых и коммерческих приложений. В VMware обнаружили, что приложения на основе NoSQL работают на 15% быстрее с использованием ESA. Это довольно значимо, учитывая что процессор, память и сетевая задержка часто являются наиболее распространенными препятствиями для производительности в среде NoSQL.
Хотя показатели производительности ESA весьма впечатляющи, учитывая постоянные улучшения производительности, внесенные в vSAN OSA, есть и второстепенные преимущества ESA, которыми не следует пренебрегать.
Эффективное использование ресурсов. ESA потребляет меньше аппаратных ресурсов для обработки и хранения данных. Это означает, что в сравнении с OSA вам, возможно, понадобится меньше хостов для удовлетворения тех же требований к рабочей нагрузке, или вы сможете запускать больше рабочих нагрузок на том же объеме оборудования. Оба варианта эффективно снижают затраты на владение виртуальной средой.
Повышенная стабильность и производительность. Более эффективный стек хранения уменьшает спрос на физические ресурсы, такие как процессор, и может помочь повысить стабильность уровня производительности, предоставляемого гостевым ВМ. Это может быть особенно важно для систем, которые являются критически важными и которые должны иметь не только низкий уровень задержек, но и стабильность в плане производительности.
Лучшая эффективность использования пространства. vSAN ESA предлагает улучшенную эффективность использования пространства без компромиссов. В отличие от OSA, он может надежно хранить данные с использованием кодирования RAID-5/6 при производительности на уровне RAID-1. Это обеспечивает гарантированную эффективность использования пространства при надежном хранении данных. ESA также может сжимать данные с минимальным использованием ресурсов и даже уменьшать использование пропускной способности канала.
Проще в управлении. Идея "производительности без компромиссов" также улучшает управление. Рекомендации по оптимизации для достижения наилучшей возможной производительности стали проще с vSAN ESA (подробнее об этом рассказано тут).
На этом пока все, ну а завтра мы расскажем, собственно, о самом механизме Adaptive Write Path и других нововведениях VMware vSAN 8 Update 1.
Там приведены результаты тестирования производительности рабочих нагрузок обучения AI/ML на платформе виртуализации VMware vSphere с использованием нескольких графических процессоров NVIDIA A100-80GB с поддержкой технологии NVIDIA NVLink. Результаты попадают в так называемую "зону Голдилокс", что означает область хорошей производительности инфраструктуры, но с преимуществами виртуализации.
Результаты показывают, что время обучения для нескольких тестов MLPerf v3.0 Training1 увеличивается всего от 6% до 8% относительно времени тех же рабочих нагрузок на аналогичной физической системе.
Кроме того, в документе показаны результаты теста MLPerf Inference v3.0 для платформы vSphere с графическими процессорами NVIDIA H100 и A100 Tensor Core. Тесты показывают, что при использовании NVIDIA vGPU в vSphere производительность рабочей нагрузки, измеренная в запросах в секунду (QPS), составляет от 94% до 105% производительности на физической системе.
vSphere 8 и высокопроизводительная виртуализация с графическими процессорами NVIDIA и NVLink.
Партнерство между VMware и NVIDIA позволяет внедрить виртуализированные графические процессоры в vSphere благодаря программному слою NVIDIA AI Enterprise. Это дает возможность не только достигать наименьшего времени обработки для виртуализированных рабочих нагрузок машинного обучения и искусственного интеллекта, но и использовать многие преимущества vSphere, такие как клонирование, vMotion, распределенное планирование ресурсов, а также приостановка и возобновление работы виртуальных машин.
VMware, Dell и NVIDIA достигли производительности, близкой или превышающей аналогичную конфигурацию на физическом оборудовании со следующими настройками:
Dell PowerEdge R750xa с 2-мя виртуализированными графическими процессорами NVIDIA H100-PCIE-80GB
Для вывода в обеих конфигурациях требовалось всего 16 из 128 логических ядер ЦП. Оставшиеся 112 логических ядер ЦП в дата-центре могут быть использованы для других задач. Для достижения наилучшей производительности виртуальных машин во время обучения требовалось 88 логических ядер CPU из 128. Оставшиеся 40 логических ядер в дата-центре могут быть использованы для других активностей.
Производительность обучения AI/ML в vSphere 8 с NVIDIA vGPU
На картинке ниже показано сравнительное время обучения на основе тестов MLPerf v3.0 Training, с использованием vSphere 8.0.1 с NVIDIA vGPU 4x HA100-80c против конфигурации на физическом оборудовании с 4x A100-80GB GPU. Базовое значение для физического оборудования установлено как 1.00, и результат виртуализации представлен в виде относительного процента от базового значения. vSphere с NVIDIA vGPUs показывает производительность близкую к производительности на физическом оборудовании, где накладные расходы на виртуализацию составляют 6-8% при обучении с использованием BERT и RNN-T.
Таблица ниже показывает время обучения в минутах для тестов MLPerf v3.0 Training:
Результаты на физическом оборудовании были получены Dell и опубликованы в разделе закрытых тестов MLPerf v3.0 Training с ID 3.0-2050.2.
Основные моменты из документа:
VMware vSphere с NVIDIA vGPU и технологией AI работает в "зоне Голдилокс" — это область производительности для хорошей виртуализации рабочих нагрузок AI/ML.
vSphere с NVIDIA AI Enterprise, используя NVIDIA vGPUs и программное обеспечение NVIDIA AI, показывает от 106% до 108% от главной метрики физического оборудования (100%), измеренной как время обучения для тестов MLPerf v3.0 Training.
vSphere достигла пиковой производительности, используя всего 88 логических ядер CPU из 128 доступных ядер, оставив тем самым 40 логических ядер для других задач в дата-центре.
VMware использовала NVIDIA NVLinks и гибкие группы устройств, чтобы использовать ту же аппаратную конфигурацию для обучения ML и вывода ML.
vSphere с NVIDIA AI Enterprise, используя NVIDIA vGPU и программное обеспечение NVIDIA AI, показывает от 94% до 105% производительности физического оборудования, измеренной как количество обслуживаемых запросов в секунду для тестов MLPerf Inference v3.0.
vSphere достигла максимальной производительности вывода, используя всего 16 логических ядер CPU из 128 доступных, оставив тем самым 112 логических ядер CPU для других задач в дата-центре.
vSphere сочетает в себе мощь NVIDIA vGPU и программное обеспечение NVIDIA AI с преимуществами управления дата-центром виртуализации.
Более подробно о тестировании и его результатах вы можете узнать из документа.
В этом году компания VMware серьезно взялась за доработку своих фреймворков по автоматизации операций в виртуальной инфраструктуре. Это было обусловлено тем, что исторически у VMware накопилось большое количество средств автоматизации, которые когда-то были привязаны к специфическим продуктам и интерфейсам, потом эти продукты эволюционировали, объединялись в различные линейки, а старые интерфейсы продолжали тянуться за разными решениями, управлять которыми до сих пор можно несколькими разными способами, а с учетом различных платформ и вспомогательных сервисов таких способов становится слишком много.
Использование командлетов PowerShell/PowerCLI для автоматизации предлагает множество преимуществ, таких как простота установки на множестве различных операционных систем и мощный язык сценариев, поддерживающий команды, специфичные для VMware.
PowerCLI отлично интегрируется с экосистемой VMware, обеспечивая совместимость и бесшовную интеграцию с продуктами vSphere, vSAN, NSX, VMC, SRM и другими. Несмотря на то что PowerCLI работает автономно со своим собственным циклом выпуска, VMware стремимся синхронизировать его с официальными релизами vSphere. Это гарантирует, что клиенты PowerCLI не будут долго ждать доступа к новым функциям и возможностям, поставляемым в новых версиях VMware vSphere.
Вызовы VMware PowerCLI
Как и в других сферах автоматизации, сейчас есть некоторые проблемы, с которыми сталкиваются как в самой VMware, так и клиенты при использовании PowerCLI. В первую очередь здесь стоит возможность использовать PowerCLI на всех платформах, на которых работает PowerShell. Большинство людей ассоциируют PowerShell с Microsoft Windows, что вполне логично, но PowerShell Core становится довольно популярным на платформах Linux и MacOS. VMware стремится поддерживать эти платформы на том же уровне, что и для Windows.
Во-вторых, по мере эволюции VMware vSphere и других продуктов VMware, PowerCLI также должен меняться, и делать это быстро, чтобы успевать за нововведениями продуктовой линейки. Этот быстрый темп не должен влиять на удобство использования и качество командлетов PowerCLI. Поэтому стоит задача расширения охвата PowerCLI для продуктов за более короткий период времени, при этом нужно обеспечить требуемое качество модулей и командлетов.
Поддержка нескольких платформ
Когда PowerCLI 13.0 был выпущен в ноябре 2022 года, это был первый PowerCLI, полностью совместимый с PowerShell Core, который работает на Microsoft Windows, Linux и Apple MacOS. Это означает, что образец кода или сценарий можно запустить на любой из этих платформ, запланировать с помощью cron на Linux и т.п. Это делает его очень гибким в качестве инструмента автоматизации, и это означает больше возможностей для инструментов оркестрирования операций.
Автоматизация средств автоматизации
В выпуске PowerCLI 12.4 VMware представила инновационный подход к генерации командлетов: через механизмы автоматизации. Была автоматизирована генерация командлетов для vSphere Automation API, которая была выпущена в рамках нового модуля под названием VMware.SDK.vSphere. Этот подход позволяет быстро создавать командлеты и модули для поддержки новых функций, обеспечивая при этом качество и последовательность.
Однако успех этой стратегии во многом зависит от качества API самих продуктов. Ближайшая цель VMware - обеспечить выпуск API с высокими стандартами качества, которые также соответствуют требованиям PowerCLI.
Обширность покрытия
В последующих релизах после 12.4 продолжали внедрять новые модули PowerCLI на основе подхода автоматического генерирования, такие как модули VMware.Sdk.Nsx.Policy, VMware.Sdk.SRM и VMware.Sdk.VR.
Например, введенный в PowerCLI 12.6 модуль VMware.Sdk.Nsx.Policy позволяет клиентам управлять NSX Policy API и является важной частью мультиоблачных операций, помогая устанавливать контроль над безопасностью, независимо от того, где работает ваша нагрузка.
В выпуске 12.7 были добавлены новые командлеты для указания пороговых значений проверки "здоровья" vSAN в рамках модуля VMware.CimAutomation.Storage.
Выпуск 13.0 сделал PowerCLI мультиплатформенным инструментом, что также означало, что модули, такие как VMware.ImageBuilder и VMware.DeployAutomation, должны быть совместимы с Apple MacOS и Linux. Кроме того, были добавлены новые команды для управления дисками кластера vSAN ESA и обновлен модуль VMware.VimAutomation.Cloud для поддержки функций API VMware Cloud Director 10.4.
В последнем на данный момент выпуске PowerCLI 13.1, было представлено два новых модуля: VMware.Sdk.VR для поддержки REST API VMware vSphere Replication и VMware.Sdk.Srm для поддержки REST API VMware Site Recovery Manager. Также там добавили новые командлеты для офлайн-депозиториев Lifecycle Manager, удаленного управления хранилищем данных vCenter Server, прямого управления дисками vSAN, выключения кластера, монтирования удаленных хранилищ данных vSAN из расширенных кластеров vSAN и многого другого.
Что дальше?
Следующие шаги - это поддержание высокого уровня удобства использования и качества модулей и командлетов PowerCLI. VMware продолжает улучшать собственные инструменты, которые генерируют автоматизированные команды, а также проверяют и верифицируют исходные API в самих продуктах на предмет качества. Эти усилия приносят пользу всем средствам автоматизации, а не только PowerCLI.
Также будет расширяться охват PowerCLI за счет введения новых модулей и улучшений в существующих. Хорошим примером является поддержка автоматизации VMware Cloud Foundation, позволяющая клиентам контролировать, настраивать и автоматизировать эти среды так же легко, как они делают это с vSphere.
Наконец, будем продолжать поддерживаться кроссплатформенность, что позволит пользователям Windows, Linux и MacOS на равных использовать PowerCLI.
На сайте проекта VMware Labs вышло очередное обновление утилиты vSphere Diagnostic Tool 1.1.6. Напомним, что это python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О последнем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.
Давайте посмотрим на новые возможности vSphere Diagnostic Tool 1.1.5:
Общие улучшения:
Увеличен таймаут проверок с 10 до 20 секунд
Исправлена проблема, когда версия/топология идентифицировались некорректно
Проверка VC VMDIR:
Была добавлена проверки Domain Functional Level (DFL) для обнаружения дополнительных возможных проблем
Проверка сертификатов vCenter:
Проверка идентификатора ключа на предмет того, что он не заполнен
Новая проверка для подсчета объектов CRL в разделе TRUSTED_ROOT_CRLS
Скачать VMware vSphere Diagnostic Tool 1.1.6 можно скачать по этой ссылке.
Он раскрывает аспекты производительности виртуальных машин, работающих в инфраструктуре решений вендоров VMware, Oracle, AMD и Deloitte:
В этом документе рассматривается, как именно Oracle Cloud VMware Solution (OCVS) отличается от публичных облачных сред IaaS. Там также приводится описание следующих процессов:
Перенос виртуальных машин Oracle и SQL Server из локального датацентра в облако OCVS без перенастройки с обеспечением того же уровня производительности.
Демонстрация, как облако OCVS, работающее на оборудовании с процессорами AMD EPYC, достигает повышения производительности баз данных.
Наглядно показывается, что NSX Data Center может ускорить работу с нагрузками Oracle со ссылками на исследования VMware и Deloitte Consulting.
Обоснование экономических и технических преимуществ управления хостами со стороны клиентов.
Об облаке OCVS
OCVS включает следующие продукты VMware: vSphere, vSAN, NSX Data Center и vCenter Server. Эта унифицированная облачная инфраструктура и платформа для операций позволяет ИТ-специалистам предприятий быстро переносить и модернизировать приложения, бесшовно перемещая рабочие нагрузки между локальными средами и инфраструктурой Oracle Cloud Infrastructure (OCI) в больших масштабах. Кроме того, ИТ-команды могут легко использовать такие сервисы, как Oracle Autonomous Database, Oracle Exadata Cloud и Oracle Database Cloud, имея постоянный доступ к облачному порталу и современные API.
Производительность OCVS
VMware vSphere - это проверенная корпоративная платформа виртуализации, которая успешно работает с виртуальными машинами Oracle более 12 лет. Как показано на рисунке ниже, виртуальная машина Oracle Database, выполняющая сложную корпоративную нагрузку в OCVS, работает почти так же хорошо, как и в локальном датацентре. Когда мы масштабируем виртуальные машины Oracle Database до 8, виртуальные машины на OCVS работают даже немного лучше, чем виртуальные машины в локальных средах.
Также, используя эталонный тест VMware для измерения производительности базы данных DVD Store, компания Deloitte в независимом исследовании показывает, что виртуальные машины Oracle Database работают до 4-8 раз быстрее с VMware NSX, как показано на рисунке:
Недавно мы писали о новом релизе фреймворка для управления виртуальной инфраструктурой VMware PowerCLI 13.1. У данного средства есть очень много командлетов для автоматизации задач в различных продуктах VMware. Сегодня мы поговорим о том, как с помощью PowerCLI можно управлять задачами репликации в Site Recovery Manager (SRM) и vSphere Replication (VR). Данные операции осуществляются через REST API.
1. Подключение к серверу vSphere Replication через Connect-VrServer
Чтобы подключиться к серверу управления vSphere Replication, необходимо использовать команду Connect-VrServer. Репликация может быть настроена внутри одного сервера vCenter или между локальными и удаленными экземплярами сервера vCenter.
При настройке репликации внутри одного и того же сервера vCenter, вы можете подключиться только к локальному сайту репликации vSphere. В параметре Server укажите адрес сервера vSphere Replication. В параметрах User и Password укажите имя пользователя и пароль для экземпляра сервера vCenter, где развернут виртуальный модуль vSphere Replication.
Давайте рассмотрим объект VrServerConnection, возвращаемый командой Connect-VrServer. Он содержит свойство ConnectedPairings:
Это свойство является словарем, где хранятся все подключенные пары. Пара - это представление в API VR парных локального и удаленного сайтов. Поскольку мы только что прошли аутентификацию только на локальном сайте VR, в словаре содержится только одна запись. Это самоподключение локального vCenter.
Вы можете индексировать этот словарь по имени vCenter и получить определенный объект Pairing. Вам понадобится этот объект Pairing для вызова различных операций из API VR:
Чтобы аутентифицироваться на удаленном сервере vCenter, вы будете использовать другой набор параметров команды Connect-VrServer. Обратите внимание, что у вас должна быть настроена пара сайтов между локальным и удаленным сайтами vSphere Replication.
На этот раз для параметра LocalServer укажите уже доступный объект VrServerConnection. Для параметра RemoteServer укажите имя удаленного VC. Для параметров RemoteUser и RemotePassword укажите имя пользователя и пароль удаленного VC. Обратите внимание, что с VR мы можем настроить несколько удаленных сайтов:
Теперь, если вы проверите свойство ConnectedPairings объекта VrServerConnection, вы увидите, что в словаре появилась вторая пара, позволяющая вам вызывать операции API на удаленном сайте:
В качестве альтернативы вы можете аутентифицироваться на локальном и удаленном сайтах с помощью одного вызова Connect-VrServer:
Для начала вам нужно получить ВМ, которую вы хотите реплицировать. Используйте команду Invoke-VrGetLocalVms, для которой нужно указать параметры PairingId и VcenterId. У нас есть эти идентификаторы в объекте Pairing, который мы сохранили в переменной $remotePairing:
Вы также можете применить фильтр к этому вызову. Параметр FilterProperty указывает свойство ВМ, которое будет использоваться для поиска. В данном случае это свойство Name. Параметр Filter указывает значение свойства, которое вы ищете. Результатом этого вызова является объект VirtualMachineDrResponseList, который содержит список ВМ, соответствующих указанному фильтру. В нашем случае это будет список с одной ВМ:
Настройка HDD-дисков машин для репликации
При настройке репликации на основе хоста, вы должны указать жесткие диски ВМ, которые будут реплицированы. Для каждого реплицируемого диска вы должны указать хранилище данных на целевом vCenter. В этом примере мы будем реплицировать все жесткие диски нашей ВМ на одном целевом хранилище данных на удаленном vCenter.
Вот как получить целевое хранилище данных на удаленном vCenter, используя команду Invoke-VrGetVrCapableTargetDatastores:
Здесь для VcenterId укажите идентификатор удаленного vCenter. Укажите параметры FilterProperty и Filter, чтобы выбрать целевое хранилище данных по имени.
Жесткие диски доступны в свойстве Disks нашего объекта VirtualMachine, сохраненного в переменной $replicatedVm.
Пройдитесь по списку Disks и инициализируйте объекты ConfigureReplicationVmDisk для каждого жесткого диска. Сохраните эти конфигурации в переменной массива $replicationVmDisks:
Сначала вам нужно инициализировать объект ConfigureReplicationSpec. Помимо различных настроек репликации, мы должны указать конфигурацию репликации диска, сохраненную в переменной $replicationVmDisks, для параметра Disk. Также вам нужно указать идентификатор целевого vCenter и идентификатор реплицируемой ВМ.
Затем используйте команду Invoke-VrConfigureReplication для настройки репликации. В качестве параметров укажите PairingId и объект ConfigureReplicationSpec:
Результатом операции является объект TaskDrResponseList, который в нашем примере содержит список из одной задачи. Если хотите, вы можете указать массив объектов ConfigureReplicationSpec и реплицировать несколько ВМ одним вызовом.
Чтобы дождаться завершения задачи настройки репликации, получите задачу, пока ее свойство Status не будет равно чему-то отличному от "RUNNING":
Invoke-VrGetTaskInfo -TaskId $task.List[0].Id
В следующем разделе мы будем использовать командлеты из модуля VMware.Sdk.Srm для создания группы защиты и плана восстановления для только что созданной репликации.
3. Подключение к Site Recovery Manager с помощью Connect-SrmSdkServer
Для подключения к серверу Site Recovery Manager используйте командлет Connect-SrmSdkServer. Не используйте старый командлет Connect-SrmServer, уже доступный в модуле VMware.VimAutomation.Srm, так как он не совместим с командлетами модуля VMware.Sdk.Srm.
Site Recovery Manager поддерживает только одно соединение между локальными и удаленными сайтами SRM. Вы можете подключиться либо только к локальному сайту, либо вы можете аутентифицироваться на удаленном сайте сервера vCenter в том же вызове. Поскольку далее мы будем создавать группу защиты и план восстановления, мы выберем второй вариант. Обратите внимание, что у вас должна быть настроена пара сайтов между локальными и удаленными сайтами SRM.
Если мы посмотрим на объект SrmServerConnection, возвращенный командлетом Connect-SrmSdkServer, мы увидим, что он содержит свойство с именем ConnectedPairing. В этом случае это один объект Pairing, который представляет пару между локальным и удаленным сайтами SRM. Вам потребуется этот объект Pairing для вызова различных операций из API SRM:
4. Создание Protection Group и Recovery Plan для Host Based Replication
В этой главе мы будем использовать репликацию на основе хоста, которую мы настроили ранее. Сначала мы инициализируем HbrProtectionGroupSpec с уже реплицированной ВМ:
В этом примере мы повторно используем идентификатор ВМ, который мы сохранили в переменной $replicatedVm, поскольку он совместим между API VR и SRM. Если вам нужно получить реплицированную ВМ с помощью модуля VMware.Sdk.Srm, используйте командлет Invoke-SrmGetReplicatedVms:
Чтобы завершить этот пример, мы создадим Recovery Plan для Protection Group. Для этого сначала инициализируйте RecoveryPlanCreateSpec, требуемый командлетом Invoke-SrmCreatePlan:
После того, как вы закончили взаимодействовать с сервером SRM, закройте соединение, используя командлет Disconnect-SrmSdkServer:
Disconnect-SrmSdkServer "MySrmAddress.com"
Чтобы закрыть соединение с сервером VR, используйте командлет Disconnect-VrServer:
Disconnect-VrServer "MyVrAddress.com"
Вы можете объединить модули PowerCLI VMware.Sdk.Vr и VMware.Sdk.Srm для автоматизации всего сценария создания репликации на основе хоста и использования ее с группой защиты и планом восстановления. Если вы хотите автоматизировать репликацию на основе массива, доступную с модулем VMware.Sdk.Srm, обратитесь к статье "Array Based Replication with PowerCLI 13.1". Также вы можете ознакомиться со статьей "vSphere Replication REST API with PowerShell: Configure VM replication".
Таги: VMware, SRM, PowerCLI, Replication, Automation, DR
На сайте проекта VMware Labs обновилась утилита vSphere Diagnostic Tool
до версии 1.1.5. Напомним, что она представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О последнем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.
Давайте посмотрим на новые возможности vSphere Diagnostic Tool 1.1.5.
VDT 1.1.5 больше не поддерживает vCenter 6.7, хотя многие проверки все еще будут работать. 1.1.4 останется доступной для тех, кто все еще нуждается в ней для продуктовой линейки 6.x.
Учетные данные теперь проверяются в самом начале. Пользователю сообщается, что проверки, требующие аутентификации, не будут запускаться, если проверка пароля трижды не удастся.
Поведение при тайм-ауте изменилось. Теперь он предлагает пользователю пропустить проверку или позволить ей выполниться, вместо того чтобы требовать флаг --force.
Проверка базы данных vCenter:
Проверка VCDB теперь показывает уровни статистики, а также политики хранения задач и событий.
Выходные данные проверки VCDB теперь соответствуют результатам из KB 1028356.
Проверка vCenter VMDIR:
Проверка vmdir теперь включает информацию о партнерах ELM и тестирует подключение к портам через 389, 443, 2012 и 2020 к ним.
Старая проверка портов была удалена в пользу описанной выше.
Проверка vmdir теперь ищет устаревшую (нативную) конфигурацию PSC HA в реестре likewise.
Проверка сертификата vCenter:
Срок действия сертификата теперь отображается с каждым сообщением о сертификате.
Сертификат vmdir от 6.0 больше не включен в список проверок сертификатов.
Исправление ошибок:
VDT теперь декодирует в utf-8, а не в ascii, чтобы избежать ошибок парсинга.
Обновлены ссылки на KB.
Скачать vSphere Diagnostic Tool 1.1.5 можно по этой ссылке.
В начале прошлого года мы рассказывали о ситуации вокруг продукта VMware vCenter Converter, предназначенного для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere. На тот момент Converter был убран из списка доступных загрузок из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивался - последний релиз VMware vCenter Converter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет и до этого.
Что нового появилось в финальной версии vCenter Converter Standalone 6.4:
Добавлена поддержка контроллеров дисков NVMe
Добавлена поддержка паравиртуальных SCSI-контроллеров дисков
Добавлена поддержка виртуальных машин, совместимых с виртуальным аппаратным обеспечением до версии 20
Добавлена поддержка VMware vSphere 8.0 в части vCenter 8.0 и VMware ESXi 8.0
Добавлена поддержка VMware Workstation 17 и VMware Fusion 13
Добавлена возможность конвертации для экземпляров Amazon EC2 (из AWS EC2 в VMware vSphere или VMware Cloud on AWS)
Добавлена возможность конвертации для ВМ с UEFI Secure Boot
Добавлена возможность конвертации для Microsoft VBS
Улучшена подсистема безопасности vCenter Converter
Некоторые ограничения продукта Converter Standalone мы привели ниже.
Для Windows:
Когда вы конвертируете источники UEFI, Converter Standalone не копирует переменных UEFI в целевую машину.
Синхронизация поддерживается только для volume-based клонирования на блочном уровне.
Если у вас файловая система ReFS, то изменение размера кластера во время операции конвертации не поддерживается.
Для Linux:
Конвертация машин с дисковыми контроллерами NVMe не поддерживается.
Поддерживается только volume-based клонирование на файловом уровне.
Поддерживаются только managed destinations.
Конвертация включенных машин Linux поддерживается только если исходная операционная система использует загрузчик GRUB. Альтернативные загрузчики, такие как LILO и LOADLIN, и дополнительное программное обеспечение, изменяющее конфигурацию GRUB или процесс загрузки, такое как Trusted Boot, не поддерживаются.
При конвертации источников UEFI, Converter Standalone копирует только текущую опцию загрузочной записи UEFI в целевую машину.
Одновременное клонирование нескольких дисков и томов поддерживается только при конвертации виртуальной, а не физической машины Linux.
Установка VMware Tools на гостевых операционных системах Linux не поддерживается.
Скачать VMware vCenter Converter Standalone 6.4 можно по этой ссылке. Release Notes доступны тут.
Мы еще не рассказывали о новых функциях по обнаружению виртуальных машин-зомби, над которыми компания VMware ведет работу уже довольно давно. Между тем, эти функции могут быть очень и очень полезны в больших инфраструктурах.
VMware определяет "зомби" как виртуальные машины и серверы, которые изначально были развернуты для конкретной цели, но больше не выполняют полезной работы. VMware обнаружила, что зомби-ВМ распространены в облачных средах клиентов (а это от 15% до > 50% от всех серверов и виртуальных машин).
Такая ситуация может влечет за собой лишние затраты и угрозы в плане безопасности, а также огромное воздействие на окружающую среду в виде неиспользуемой инфраструктурной мощности, потребления энергии и выбросов углерода.
Например, в 2019 году, завершая миграцию дата-центра, VMware обнаружила, что 47% ее виртуальных машин не используются и были устаревшими! Зомби-ВМ так распространены, потому что их легко создать (подумайте, сколько у вас зомби-приложений на телефоне?), но их может быть сложно найти. Продукты VMware vRealize Operations и CloudHealth могут помочь найти те, которые выключены или имеют низкую или нулевую загрузку процессора. Однако, многие зомби-ВМ имеют некую остаточную активность, которая вспомогательна по отношению к основному приложению, такую как сканирование на вирусы, обновление патчей и резервное копирование. Современные детекторы пропустят эти "ползучие зомби", потому что, основываясь на их активности, они выглядят так, будто они могут выполнять продуктивную работу.
Чтобы решить эту проблему, VMware тестирует подход, который отслеживает виртуальные машины на протяжении всего их существования и наблюдает за резким и постоянным снижением их активности. Любая сезонная и квазипериодическая активность при этом учитывается. Если оставшаяся активность постоянно низкая, то виртуальная машина становится потенциальным "зомби" и подвергается дальнейшему наблюдению.
Совпадающее поведение зомби-ВМ по нескольким метрикам активности подкрепляет ее статус. Поскольку работающие с полезной нагрузкой виртуальные машины могут оставаться неактивными на длительные периоды (недели или месяцы), система обнаружения зомби-ВМ терпелива, чтобы минимизировать ложные срабатывания. Если виртуальная машина снова становится активной, она удаляется из списка потенциальных зомби-ВМ. В конечном итоге, целью VMware является определение такх машин в облачных средах клиентов, выделение связанных с ними финансовых и углеродных затрат и предоставление вариантов устранения (например, с помощью Virtual Machine Desired State Configuration) для снижения затрат и освобождения ресурсов. VMware находится в процессе тестирования этого на данных клиентов, чтобы уточнить алгоритм обнаружения.
На картинке выше, ряд метрик отражает использование ресурсов с резким падением с около 80% до нового стабильного состояния - около 20%. Красные пунктирные вертикальные столбцы показывают область аномалии смены точек, а фиолетовые точки указывают на путь среднего предиктора с уменьшающейся величиной через область аномалии. Серые треки - это асимметричные погрешности вокруг среднего предиктора с уменьшающейся величиной. В какой-то момент ряд достаточно выравнивается, чтобы подтвердить постоянное, более низкое состояние активности. В этом случае "новая норма" выглядит как остаточный фон, состоящий из периодической активности малой амплитуды. Этот остаточный сигнал анализируется на предмет известного класса непродуктивного фона, такого как регулярное сканирование на вирусы или накатывание патчей.
Пока эти функции еще не внедрены в VMware vSphere, но их появление ожидается уже в самом ближайшем будущем.
Photon OS 5.0 использует механику Long-Term Support Kernel 6.1, включая обновления различных вариантов ядра Linux, предлагаемых для Photon OS:
linux - общий вариант ядра
linux-esx - ядро Linux, настроенное для гипервизора VMware и используемое в CRX и POD VM
linux-secure - укрепленное с точки зрения безопасности ядро для развертывания на Edge-компонентах
linux-rt - ядро Linux, настроенное для использования с низкими задержками (latency) и используемое в модулях Telco VRAN, включая оптимизации, улучшения стабильности и поддержку процессоров Intel Sapphire Rapids. Обратите внимание, что вариант ядра linux-aws из предыдущих версий теперь объединен с общим ядром linux.
2. Различные нововведения
Установщик Photon OS теперь поддерживает файловые системы XFS и BTRFS. С cgroupsv2 пользователи теперь могут воспользоваться улучшенными возможностями управления ресурсами, единой иерархией дизайна в API и информацией Pressure Stall, среди прочих преимуществ cgroupsv2. Кроме того, Photon OS 5.0 теперь поддерживает ARM64 для варианта ядра linux-esx.
3. Улучшения безопасности и Rootless Containers
Photon OS 5.0 вводит функцию "живого" обновления ядра, позволяющую администраторам обновлять работающее ядро без перезагрузки. Кроме того, в этом релизе поддерживается политика SELinux для управления доступом к файлам, каталогам и другим системным ресурсам, что позволяет администраторам минимизировать нарушения безопасности. Rootless Containers позволяют непривилегированным пользователям создавать и управлять контейнерами без прав root на хост-машине, что дополнительно предотвращает угрозы для хоста.
4. Упрощение управления сетью
Photon OS 5.0 принес ряд улучшений в Network Configuration Manager, ориентированных на упрощении задач администрирования сети. Администраторы могут определить YAML-файл для выполнения настройки сети с использованием синтаксиса Netplan. В этом релизе можно выполнять настройку и администрирование различных параметров сетевых устройств - нескольких маршрутов и разделов адресов, настройка Wire Guard и SRIOV, а также управление виртуальными сетевыми устройствами. Модуль pmd-nxtgen улучшен для настройки системного имени хоста, настройки сетевого SRIOV, Tun, TLS и т. д.
5. Улучшения установщика, системы билдов и tdnf
Администраторы теперь могут создавать пользовательский RAM-диск (initrd), ISO-образ и RPM-OSTree ISO с использованием инструментов командной строки - это дает более гибкое управление интерфейсами VLAN с конфигурациями сети Kickstart. Система разделов A/B упрощает обновления и откаты. Tdnf теперь имеет несколько новых параметров командной строки, таких как история, метка и т. д. Кроме того, добавлены дополнительные параметры для улучшения опыта установки и обновления пакетов.
6. Обновления пакетов
Как и каждый крупный релиз, версия 5.0 включает обновления таких пакетов, как gcc (12.2), glibc (2.36), systemd (253), python3 (3.11), openssl (3.0.8), go (1.20.2) и т. д. Обратите внимание, что некоторые пакеты были объявлены устаревшими. Для подробной информации об обновлениях пакетов ознакомьтесь с разделом What's New. Кроме того, в Photon OS 5.0 поддерживаются версии PostgreSQL 13, 14 и 15.
Подробно о новых возможностях VMware Photon OS 5.0 можно на странице проекта на GitHub. Скачать ISO-образы и другие дистрибутивы можно по этой ссылке.
Давайте посмотрим, что нового появилось в этом обновлении:
1. Новые модули SDK для SRM и vSphere Replication
С релизом SRM и vSphere Replication 8.6 эти два продукта получили новые REST API. Фактически, это был первый публичный API, выпущенный для vSphere Replication. Это дало возможность автоматически создавать модули PowerCLI для этих продуктов, как это уже было ранее для NSX и vSphere. Как и в случае с vSphere, теперь можно найти примеры PowerCLI непосредственно в документации REST API vSphere Replication и SRM.
2. Улучшения vLCM
В PowerCLI 13.1 были добавлены новые параметры в командлет Set-VMHost, которые позволяют задавать конфигурацию LCM хоста ESXi таким же образом, как вы задаете конфигурацию LCM кластера. Это новая функция, поддерживаемая только в vSphere 8.0 Update 1. Также были представлены командлеты для создания новых офлайн-репозиториев LCM с помощью PowerCLI.
3. Новые командлеты для vSAN
PowerCLI 13.1 имеет большое количество новых функций для vSAN. Появились новые командлеты для управления удаленным хранилищем данных vSAN, прямого управлением дисками и выключения кластера vSAN.
4. Изменения в VMware Cloud Director
Для VMware Cloud Director был изменен механизм аутентификации Connect-CIServer, и теперь он аутентифицируется через новый эндопоинт аутентификации API vCD. Это позволит без проблем работать командлету с будущими версиями vCD. Также был обновлен командлет Import-CIVappTemplate для работы с последними версиями API. В связи с этим, были внесены некоторые изменения в интерфейс командлета, что может привести к необходимости переработки некоторых ваших скриптов Cloud Director.
5. Поддержка модуля ImageBuilder для Python
В PowerCLI 13.0 модули ImageBuilder и AutoDeploy были портированы для работы на платформах Linux и MacOS. Это требует от пользователей иметь предустановленный Python для работы этих модулей. В версии 13.0 они поддерживали только Python 3.7.x, теперь же поддерживаются все версии выше Python 3.7.1.
Загрузить обновленную версию VMware PowerCLI 13.0 можно по этой ссылке. Документация доступна тут.
В начале прошлого года мы рассказывали о ситуации вокруг продукта VMware vCenter Converter, предназначенного для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere. На тот момент Converter был убран из списка доступных загрузок из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивался - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого.
В октябре прошлого года был впервые выпущен релиз vCenter Converter Standalone 6.3, где было много новых возможностей, необходимость в которых копилась еще с 2018 года. Ну а вот на днях VMware выпустила очередное обновление - бету vCenter Converter Standalone 6.4, и об этом написал Вильям Лам.
Давайте посмотрим на новые возможности Converter 6.4 Beta:
Добавлена поддержка контроллеров дисков NVMe
Добавлена поддержка паравиртуальных SCSI-контроллеров дисков
Добавлена поддержка виртуальных машин, совместимых с виртуальным аппаратным обеспечением до версии 20
Добавлена поддержка VMware vSphere 8.0 в части vCenter 8.0 и VMware ESXi 8.0
Добавлена поддержка VMware Workstation 17 и VMware Fusion 13
Добавлена возможность конвертации для экземпляров Amazon EC2 (из AWS EC2 в VMware vSphere или VMware Cloud on AWS)
Добавлена возможность конвертации для ВМ с UEFI Secure Boot
Добавлена возможность конвертации для Microsoft VBS
Улучшена общая безопасность vCenter Converter
Чтобы скачать продукт и посмотреть заметки к релизу, вам нужно зарегистрироваться в бета-программе по этой ссылке.
На днях компания VMware аноснировала финальную доступность продукта GemFire 10. GemFire - это высокопроизводительная база данных в оперативной памяти для приложений с низкими задержками (latency). Сфокусированная на надежности и консистентности, GemFire обеспечивает простоту масштабирования данных и поддержку критически важных для бизнеса приложений, будь то онпремизная площадка, облако или промежуточные локации.
GemFire 10 был предварительно анонсирован на конференции SpringOne Essentials в январе, а позже был выпущен в качестве общедоступной бета-версии. С тех пор VMware упорно работала над окончательным выпуском.
Эта новая версия является значительным этапом в эволюции GemFire, которая активно развивается уже более 21 года, начиная с ее создания в 2002 году.
Давайте посмотрим на новые возможности GemFire 10:
VMware GemFire Management Console – новый управляющий интерфейс позволяет разработчикам и операторам настраивать и управлять кластерами GemFire. Отсюда видны все объекты ваших развертываний GemFire.
VMware GemFire Search - разработчики могут реализовать все возможности полнотекстового поиска в своих приложениях, которые могут работать очень быстро при исполнении их в памяти. Поиск и индексирование реализованы в рамках одного продукта.
VMware GemFire for Redis Apps - этот релиз расширяет совместимость с приложениями Redis и добавляет поддержку новых политик в модуле расширения.
Spring for VMware GemFire - улучшенная совместимость и долговременная поддержка для приложений Spring.
JSON document improvements - теперь есть возможности хранения документов BSON или нативных объектов Portable Data eXchange для in-memory приложений с реализацией хранилища, оптимизированного по пространсту хранения.
Java 17 support - GemFire был полностью оттестирован для Java 17. Сборщик Z Garbage Collector выбран по умолчанию, что дает лучшую производительность для больших размеров кучи.
Jakarta Enterprise Edition (JEE) 9 - модули репликации состояния сессии теперь поддерживают Apache Tomcat 10 и Jakarta EE 9.
Pluggable modules - разработчики могут упаковывать и развертывать server-side компоненты независимо, без конфликтов с существующими библиотеками GemFire.
Cross-cluster replication improvements - объекты приложений, которые хранят частичные апдейты, могут быть более эффективно реплицированы в другие кластеры.
Updated defaults - были улучшены параметры для тюнинга, что дает меньше затрат на первоначальную конфигурацию и установку.
Deploy and run everywhere - GemFire может быть запущен в онпремизной инфраструктуре или в облаке, а также в виртуальных машинах, физических или в контейнерах. Также доступны функции автоматизированного управления и бесшовных апгрейдов для Kubernetes и VMware Tanzu Application Service.
Загрузить GemFire 10 можно по этой ссылке. Developer Center находится тут, а документация здесь.
На днях компания VMware выпустила первую версию плагина, предназначенного для исполнения типовых сценариев PowerCLI - Power Actions 1.0. Об этом средстве мы уже упоминали, когда в начале 2021 года компания VMware выпустила обновленную версию vSphere HTML5 Web Client.
Power Actions - это плагин клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI с пользователями, не имеющими опыта работы с PowerShell. Это средство также предоставляет библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации. Пользователи могут легко выполнить эти скрипты, используя удобный пользовательский интерфейс для указания параметров скрипта. Это обеспечивает мощный механизм расширения клиента vSphere с помощью настраиваемых сценариев PowerCLI.
А что насчет безопасности и прав доступа? Все скрипты выполняются с использованием прав пользователя, который вошел в клиент vSphere. Таким образом, если у пользователя нет разрешения на выполнение определенных операций, он не сможет выполнить эти операции с помощью Power Actions.
1. Установка
Power Actions распространяется в виде виртуального модуля (Virtual Appliance). Вы можете загрузить файл OVA со страницы Power Actions на сайте VMware Labs. Там же вы можете загрузить полное руководство пользователя, которое содержит подробные инструкции по установке. После установки Power Actions вы можете использовать его через Developer Center в клиенте vSphere.
2. Библиотека сценариев
Основная функция Power Actions - запуск сценариев из вашей библиотеки сценариев. Поэтому первым делом нужно создать библиотеку сценариев и загрузить в нее ваши скрипты.
Библиотеки сценариев на самом деле являются библиотеками контента, так что любую библиотеку контента можно использовать как библиотеку сценариев. Если у вас нет библиотеки контента, вы можете создать новую с помощью PowerCLI или клиента vSphere. Следующим шагом будет импорт ваших сценариев в библиотеку сценариев. Вы можете загружать сценарии по одному через клиент vSphere или целые коллекции сценариев через PowerCLI.
3. Запуск скриптов
После того, как вы загрузили свои скрипты в библиотеку, вы можете начать запускать их. У вас есть два варианта запуска скрипта - непосредственно из библиотеки или через контекстное меню. В обоих случаях, когда вы выполняете скрипт с параметрами, вам будет предложено ввести их. Однако, когда вы запускаете скрипт из контекстного меню, некоторые параметры будут автоматически заполнены для удобства.
Давайте более подробно рассмотрим, как это работает. В нашей библиотеке скриптов Power Actions мы импортировали простой скрипт PowerCLI, который создает снапшоты коллекции виртуальных машин. Вот как выглядит этот скрипт:
Когда мы запустили сценарий из библиотеки, мы получим диалог, в котором нам нужно указать обязательные параметры:
Если мы хотим выполнить сценарий из контекстного меню, мы можем кликнуть правой кнопкой по виртуальной машине и выбрать "Power Actions" -> "Run script".
В итоге, мы получим диалог, где нужно выбрать скрипт для исполнения, и потом нам нужно будет ввести параметры. В этом случае в список параметров будут автоматически добавлены параметры ВМ, для которой мы вызвали контекстное меню:
4. Мониторинг исполнения сценариев и просмотр результатов
На следующем экране Power Actions мы увидим представление "Script run". Здесь мы можем отслеживать выполнение скриптов и просматривать результаты исполнения. Также на этой странице можно остановить выполнение сценария.
5. Консоль сценария
Еще одна полезная возможность Power Actions - это встроенная консоль PowerShell с последней предустановленной версией PowerCLI. Когда вы отроете консоль, она автоматически соединится с vCenter Server, используя текущий пользовательский аккаунт vSphere Client. Вы можете использовать эту консоль для выполнения отдельных команд или готовых командлетов. Имейте в виду, если вы переключитесь на другое представление vSphere Client или запустите еще один экземпляр Power Actions, а потом вернетесь в консоль, то ваша сессия будет создана снова, а все переменные из памяти прошлого сеанса будут потеряны.
Скачать виртуальный модуль Power Actions и документацию к нему можно по этой ссылке.
В начале февраля мы писали о том, что компания VMware выпустила бета-версию своей операционной системы Photon OS 5.0 Beta. Напомним, что эта ОС на базе Linux используется во всех виртуальных модулях (virtual appliances), выпускаемых и поддерживаемых VMware.
На этой неделе VMware выпустила релиз-кандидат версию Photon OS 5.0 RC, в которой появилось еще несколько новых возможностей, помимо тех, которые были анонсированы ранее.
В релиз-кандидате появилась долгосрочная поддержка (Long-Term Support) для Kernel 6.1
Добавлена поддержка PostgreSQL 15 (поддержка PostgreSQL 12 была убрана)
Расширения tdnf с большим количеством параметров командной строки и инструментов для управления конфигурацией tdnf
Обновления основных пакетов, таких как systemd (253.0), cloud-init (23.1.1), openssl (3.0.8) и т.д.
Теперь вы можете создавать настраиваемый образ начального RAM-диска, ISO-образа установщика и образа RPM-OSTree через командную строку.
Система разделения хранилища A/B позволяет выполнять бесшовные обновления и rollback
Конфигурация сети Kickstart Network обеспечивает улучшенную гибкость для настроек сети, которая позволяет использовать несколько интерфейсов и облегчает обработку интерфейсов VLAN
Гибкая и упрощенная конфигурация сети с использованием файлов YAML и синтаксиса конфигурации Netplan
На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.
В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.
Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):
В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:
1. Масштабирование распределенных хранилищ
Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.
Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage
В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.
Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA
В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.
Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server
vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).
2. Улучшение платформы
Улучшенная производительность с использованием нового адаптивного пути записи
В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.
Улучшенная производительность для отдельных нагрузок
Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.
Улучшенная надежность во время сценариев режима обслуживания.
В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.
Улучшения управления датасторами
В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.
3. Упрощение управления
При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.
Автоматическое управление политиками для Default Storage Policies
(ESA)
В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.
Skyline Health Score и исправление конфигурации
В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".
С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).
Более высокий уровень детализации для улучшенного анализа производительности
Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.
Упрощенный сбор диагностической информации о производительности
В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.
Новая интеграция PowerCLI
В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.
4. Функции Cloud Native Storage
Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.
Поддержка CNS для vSAN ESA
В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.
Поддержка DPp общих виртуальных коммутаторов
vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.
Развертывние Thick provisioning для vSAN Direct Configuration
Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).
Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.
Таги: VMware, vSAN, Update, Storage, OSA, ESA, Performance
На днях компания VMware объявила о том, что решения VMware Cloud on AWS Terraform Provider и Python Automation Utility for VMware Cloud on AWS теперь поддерживают аутентификацию приложений OAuth 2.0 для VMware Cloud, что позволяет зарегистрировать средства автоматизации с поддержкой этого типа аутентификации. Теперь администраторы могут управлять учетными данными, привязанными к API-токенам доступа отдельных разработчиков, на уровне организации.
Объекты OAuth app действуют как сущности в рамках коммуникаций server-to-server и могут быть использованы в разных организациях. Только пользователь, создавший API-токен, может управлять им, а владелец OAuth app - это организация, которая управляется администратором с ролью Developer. Поэтому для использования API, где не требуется связывание токена с пользователем (например, полностью автоматизированные решения), рекомендуется не использовать API-токены персональных аккаунтов.
Это позволяет избежать ситуации, когда аккаунт этого человека был деактивирован или устарел, для него изменилась роль и т.п., что может повлиять на сервисы, использующие этот токен. Вместо этого владелец объекта Organization создает OAuth App с App ID и App Secret, чтобы дать доступ приложению по API. Детали этого процесса на платформе VMware Cloud on AWS приведены вот в этой статье.
Итак, здесь есть 2 важных шага по созданию OAuth: создать объект App и назначить его объекту Org.
Для создания App нужно сделать следующее:
Логинимся в CSP, кликаем на имя пользователя и выбираем для него View Organization
Переходим на вкладку OAuth Apps в самом верху страницы
Нажимаем Create App и выбираем Server to server app
Определяем имя приложения, описание, время жизни токена (Access Token TTL, рекомендуется 30 минут). Надо помнить, что как только токен создан - уже нет способа отозвать доступ, поэтому не надо задавать слишком большое время.
Нажимаем Create. Надо помнить, что стоит максимально ограничивать роли для сервисов и действий в рамках организации минимально необходимыми привилегиями.
Скачиваем копию App ID и App Secret.
Помните, что после этого экрана вы уже не сможете скачать App Secret, но вы можете просмотреть App ID, а сам App Secret можно сгенерировать снова. Другие свойства приложения также можно редактировать после создания.
Назначаем объект App объекту Org:
Нажимаем Add после того, как вы создали App, чтобы добавить приложение в текущую организацию.
Переходим на страницу OAuth Apps со страницы View Organization (у пользователя должны быть права по добавлению в эту организацию)
Последний релиз VMware Cloud on AWS Terraform Provider был обновлен и теперь включает два новых поля в файле переменных variables.tf: client_id и client_secret. Параметр client_id - это идентификатор объекта OAuth App, ассоциированный с организацией, а client_secret - это его пароль. Оба этих параметра вместе используются для аутентификации при вызове VMware Cloud Services API. Помимо этой комбинации, вы можете использовать и один параметр api_token.
Решение Python Automation Utility for VMware Cloud on AWS также было обновлено, чтобы поддерживать метод аутентификации OAuth 2.0 app. Чтобы использовать его, нужно указать параметры oauth_clientId и oauth_clientSecret в файле config.ini, как показано в примере ниже:
По умолчанию механизм аутентификации использует API-токен, указанный в поле refresh_Token файла config.ini. Чтобы использовать новый метод аутентификации OAuth app, нужно добавить параметр -oauth при запуске команд, указанных ниже.
Пример команды для использования аутентификации по умолчанию с использованием refresh_Token:
./pyVMC.py sddc show-sddcs
А вот так нужно запускать эту команду для использования аутентификации OAuth app:
./pyVMC.py sddc show-sddcs –oauth
Для получения полного списка команд и инструкций по использованию средства Python Utility for VMware Cloud on AWS обратитесь к этому документу.
На днях компания VMware объявила о прекращении поддержки протокола PCoIP, который использовался для передачи данных удаленных десктопов на клиентское устройство в решении VMware Horizon. Напомним, что изначально этот протокол был разработан совместно компаниями VMware и Teradici, после чего вошел в состав решения VMware View 4 (сейчас актуальна уже восьмая версия этой платформы). Было это в далеком 2009 году.
Со временем на смену PCoIP пришел высокопроизводительный протокол Blast (ранее он назывался AppBlast и был анонсирован в 2011 году, а в релиз вышел в 2013), который поначалу развивался параллельно с PCoIP, но сейчас показывает лучшие результаты и является основным протоколом доставки. В связи с этим, разработка PCoIP под Horizon была остановлена, а недавно было принято решение об прекращении его поддержки.
Сейчас протокол Blast Extreme обеспечивает высокопроизводительную доставку виртуальных десктопов и приложений как во внутрикорпоративных сетях, так и через WAN-сети и интернет:
VMware по-прежнему будет включать PCoIP как опцию для протокола передачи в Horizon Client и Horizon Agent до конца 2025 года в целях поддержки существующей базы пользователей. За следующие пару лет протокол PCoIP будет исчезать из продуктов VMware, но, согласно политике компании, продукты Horizon поддерживаются еще в течение трех лет с момента релиза, так что PCoIP теоретически будет поддерживаться до 2028 года.
Во многом дело еще в том, что протокол PCoIP разрабатывается компанией Teradici, купленной HP в 2021 году, и теперь это HP Teradici. Ну а HP - это не VMware, для которой важно иметь собственный протокол. VMware продолжит сотрудничество с HP Teradici в плане разработки высокопроизводительных протоколов, в частности в клиентах HP Anyware Zero Clients (подробнее об этом тут).
Осенью прошлого года VMware анонсировала первую версию фреймворка
PowervRLICloud, предназначенного для управления окружением VMware vRealize LogInsight Cloud (этот продукт сейчас называется Aria Operations for Logs). Это PowerShell модуль, который реализует абстракции VMware vRealize LogInsight Cloud API для простого доступа к возможностям функций управления этим решением посредством сценариев.
Многие администраторы сталкиваются с необходимостью обновления пакета VMware Tools в большом количестве виртуальных машин, работающих на серверах ESXi платформы VMware vSphere.
Общие сведения об обновлении VMware Tools
На данный момент можно использовать один из трех способов массового VMware Tools в большой инфраструктуре:
Применение средства VMware vSphere Lifecycle Manager (ранее его функционал был частью VMware Update Manager)
Написание сценариев для фреймворка VMware vSphere PowerCLI
Использование сторонних утилит для обновления тулзов
В отличие от версий аппаратной обеспечения (VM Hardware), компания VMware рекомендует всегда использовать последнюю версию пакета VMware Tools, для которого есть матрицы совместимости с различными версиями хостов ESXi. Посмотреть их можно по этой ссылке.
Например, мы видим, что VMware Tools 2016 года все еще можно использовать в ВМ на ESXi 7.0 U3. Также виртуальная машина на сервере VMware ESXi 5.5 может иметь текущую версию VMware Tools (сейчас это 12.1.5).
Напомним, что VMware Tools - это не только часть дистрибутива vSphere, но и отдельный продукт, который можно скачать с портала Customer Connect.
Есть несколько вариантов по загрузке этого пакета:
Бандл для общего репозитория Locker
(например, VMware-Tools-windows-12.1.5-20735119.zip) - он используется для создания локального или общего репозитория с нужной версией VMware Tools.
Установщик в гостевой ОС, который можно запустить в ней как исполняемый файл (VMware-tools-12.1.5-20735119-x86_64.exe.zip).
Пакеты для GuestStore
(gueststore-vmtools-12.1.5-20735119-20735876.zip) - это новая возможность, которая появилась в vSphere 7.0 U2. GuestStore сделан не для обновления VMware Tools, но может использоваться для этой цели (это тема для отдельной статьи).
Офлайн VIB-пакет с тулзами (VMware-Tools-12.1.5-core-offline-depot-ESXi-all-20735119.zip) - он используется как Baseline для обновления VMware Tools на хостах.
Исторически пакет VMware Tools, в основном, выпускался для Windows и Linux. Есть также версии этого пакета и для FreeBSD, Solaris и MacOS. Здесь есть следующие нюансы:
Начиная с версии VMware Tools 10.2.0, инсталляция на базе Perl-скриптов для FreeBSD больше не поддерживается. В этом случае также надо использовать open-vm-tools.
Последняя версия тулзов для гостевых ОС Solaris - это 10.3.10.
Как мы увидим дальше, очень важно знать, какая версия VMware Tools размещена локально на хосте ESXi после его установки. Эта версия может быть использована для проверки актуальных пакетов в виртуальных машинах. Для быстрой проверки текущей версии пакета на хосте можно использовать следующую команду:
esxcli software component get | grep VMware-VM-Tools -B 1 -A 14
Если вы хотите использовать для этого PowerCLI, то можно выполнить следующий сценарий:
Итак, рассмотрим обновление VMware Tools одним из двух способов:
Обновление VMware Tools как отдельного пакета ПО
В этом случае для нужно версии тулзов можно использовать любое средство, например Microsoft System Center, которое предназначено для массового развертывания программ. Также вы можете использовать любые скрипты и другие средства в режиме тихой установки (silent install).
Обновление VMware Tools посредством функционала vSphere
При развертывании и апгрейде хостов ESXi на них помещаются соответствующие версии VMware Tools (чтобы узнать список версий, загляните сюда). По умолчанию пакеты помещаются в папку /productLocker на хосте ESXi - это symbolic link, то есть просто указатель на настроенную папку. Чтобы узнать, какая версия VMware Tools является текущей, сервер vCenter сравнивает установленную версию тулзов в ВМ с версией, которая хранится в разделе /productLocker. Если актуальная версия в гостевой ОС меньше хранящейся на хосте, то в vSphere Client вы увидите соответствующее предупреждение:
Далее вам нужно выполнить процедуру, состоящую из двух основных шагов:
Настраиваем хост ESXi для использования определенной версии VMware Tools
Автоматизируем процесс обновления тулзов в гостевых ОС виртуальных машин
Шаг 1 - Настройка хоста ESXi для использования определенной версии VMware Tools
Надо сказать, что не рекомендуется вручную обновлять содержимое папки /productLocker, так как это не поддерживаемый официально процесс, и при апгрейде хоста вы можете получить более старую версию пакета. Также вы можете использовать конкретную версию VMware Tools для всех ВМ (например, ту, что содержит исправление конкретного бага).
Используем vSphere Lifecycle Manager для обновления VMware Tools на хостах ESXi
Это рекомендуемый способ обновления пакета VMware Tools, здесь может быть использован один из двух пакетов обновления хостов в кластере:
Если вы обновляете кластер, используя базовые уровни (baselines), вы можете создать кастомный образ, который включает желаемые версии VMware Tools, либо вы можете развернуть тулзы с использованием кастомного бейзлайна.
Давайте посмотрим на обновление с использованием метода Baseline:
Просто скачиваем VMware Tools Offline VIB bundle
Загружаем бандл на vSphere Lifecycle Manager (либо VIB-пакет может быть загружен этим продуктом автоматически)
Выполняем функцию Remediate для накатывания VMware Tools для ВМ на хостах ESXi
После успешного апдейта, локальный репозиторий VMware Tools также будет обновлен.
Несмотря на то, что хост не нужно перезагружать после обновления, он все равно должен быть помещен в режим обслуживания (maintenance mode). В противном случае, процесс обновления может выглядеть успешным, но в реальности изменений на хосте не произойдет.
Теперь посмотрим на процесс обновления VMware Tools методом Single Image:
В этом случае можно изменить только версию VMware Tools, а остальное можно оставить как есть.
Создаем общий репозиторий для нужной версии VMware Tools
Этот подход создает центральный репозиторий VMware Tools для нескольких хостов. В этом случае они не будут использовать локальный репозиторий, а на общем хранилище будет использоваться общая папка, которая станет новым репозиторием. Преимуществом данного подхода является обслуживание только одного экземпляра репозитория. Процесс создания этого репозитория описан в KB 2129825.
Как это выглядит по шагам:
1. Создаем на общем томе VMFS папку и устанавливаем для нее разрешения:
cd /vmfs/volumes/datastore
mkdir vmtools-repository-name
chmod 700 vmtools-repository-name
2. Если вы хотите использовать уже использованный репозиторий, то папку надо очистить:
3. Добавляем файлы, загруженные из Customer Connect и распакованные, в эту папку - у вас получится две подпапки, содержащие нужные файлы:
На скриншоте показан пример для VMware Tools под Windows. Если вы хотите использовать старые тулзы для Linux, то их нужно добавить в папку vmtools. Также посмотрите вот эту нашу статью о VMware Tools.
5. Если вы делаете процедуру впервые, то нужно настроить хосты ESXi для использования данной папки репозитория вместо используемой локальной папки по умолчанию. Для этого вам нужно добавить расширенную настройку UserVars.ProductLockerLocation (по умолчанию она указывает на /locker/packages/vmtoolsRepo/). Напомним, что /productLocker - это символьная ссылка, поэтому нужно использовать полный путь.
Так как мы обсуждаем массовое обновление тулзов, то имеет смысл показать здесь применение данного способа с использованием PowerCLI:
Для вывода текущей директории Locker выполняем следующий командлет:
Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Select-Object Entity, Value
Для изменения директории выполняем такой командлет:
Будьте аккуратны при вызове второй команды, так как она меняет параметр на всех хостах, которые вы указали.
6. После этого вам нужно будет перезагрузить хост для обновления символьной ссылки /productLocker.
Шаг 2 - Автоматизация процесса обновления тулзов в гостевых ОС виртуальных машин
Теперь мы готовы автоматизировать апдейты VMware Tools в гостевой ОС. Так как мы говорим о массовом обновлении пакетов, то мы не будем обсуждать вариант с логином в гостевую ОС, монтирования ISO-образа и запуском exe-файла.
Сначала посмотрим, какие версии сейчас установлены в виртуальных машинах, с помощью PowerCLI. Запускаем следующую команду:
Это не самая удобная нотация, но она соответствует той, что мы видим на странице VM Summary на сервере vCenter. Для получения параметров этой команды используйте маппинг-файл версий.
4 способа автоматизации обновления VMware Tools в гостевой ОС:
1. Обновляем VMware Tools немедленно или ставим запланированную задачу через vCenter
Через интерфейс не всегда удобно работать с массовым обновлением, но в данном случае это можно сделать с помощью отфильтрованного списка ВМ и установки настроек по срабатыванию действий с объектами.
vSphere Lifecycle Manager имеет довольно мощный функционал в этом плане. Процесс обновления можно запланировать на базе состояния питания ВМ. Также можно задать опции предварительного создания снапшота ВМ.
Выбираем нужный кластер, идем на вкладку Updates и выбираем VMware Tools. Фильтруем нужные нам ВМ или выбираем все, далее кликаем Upgrade to match host. В следующих окнах у вас будет множество опций для создания запланированной задачи:
Вы можете не только настроить создания снапшота перед апдейтом, но и задать число часов, по истечении которых снапшот будет удален. Также в состав снапшота может входить и состояние оперативной памяти.
Также помните, что массовое удаление снапшотов в одно время может создать очень большую нагрузку на хранилище. Поэтому лучше снапшоты использовать только для самых критичных ВМ, которые должны сразу оказаться доступными в случае каких-либо проблем.
Дефолтные настройки для этих параметров вы можете установить здесь: Menu -> Lifecycle Manager -> Settings -> VMs:
2. Мгновенное обновление VMware Tools через vSphere PowerCLI
Для обновления тулзов на выбранных хостах (или всех) используется командлет Update-Tools. Он инициирует процесс обновления пакета изнутри гостевой ОС. По умолчанию Update-Tools ждет завершения обновления, после чего инициируется процесс перезагрузки ВМ. Это поведение можно изменить, используя параметры NoReboot и RunAsync.
Следующая команда начинает процесс обновления в виртуальной машине Win2019-01 в рамках задачи:
Get-VM Win2019-01 | Update-Tools –RunAsync
Чтобы посмотреть статус выполняемых задач, используйте команду Get-Task:
Так как это команда PowerShell - ее также можно добавить в запланированные задачи.
3. Обновление VMware Tools при следующей загрузке ВМ в интерфейсе vSphere Client
В рамках окна обслуживания виртуальные машины обычно можно перезагружать. Его, как раз, можно использовать и для обновления VMware Tools. Для этого надо настроить ВМ для проверки версии тулзов при загрузке. Если установленная версия меньше необходимой (по ссылке в /productLocker), то начинается процесс апдейта.
Для изменения политики обновлений, выберите нужный кластер и перейдите на вкладку Updates, где выберите VMware Tools. Там можно фильтровать список ВМ:
После того, как вы выберете машины, можно задать политику автообновления для них:
4. Обновление тулзов при следующей загрузке с использованием vSphere PowerCLI
Сначала посмотрим, текущую конфигурацию ВМ через PowerCLI:
Уделите особое внимание тому факту, какие ВМ вы поместите в переменную $VMs. При таком подходе для обновления VMware Tools вы не сможете запланировать создание предварительных снапшотов ВМ.
RSS
